Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POC: Self-contained headers #1423

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

hebasto
Copy link
Member

@hebasto hebasto commented Sep 11, 2023

This PR adds a tool that verifies every header whether it is self-contained.

As an example, the field_5x52.h and field_10x26.h headers have been refactored to get self-contained.

@real-or-random real-or-random added ci build refactor/smell meta/development processes, conventions, developer documentation, etc. labels Sep 12, 2023
@real-or-random
Copy link
Contributor

real-or-random commented Sep 12, 2023

Interesting!

This raises the question: Should self-containedness be tested in VERIFY mode, or non-VERIFY mode, or both? I believe at least in VERIFY mode because the goal here will be to help development tooling (e.g., clangd), and development is typically more convenient in VERIFY mode. Otherwise all #ifdef VERIFY blocks don't exist, i.e., you don't even get syntax highlighting for them...

Of course, we could manage to make this happen in both modes without too much hassle, that will be ideal.

This is related to #1039, where I suggested something like this.

@hebasto
Copy link
Member Author

hebasto commented Sep 12, 2023

This is related to #1039, where I suggested something like this.

I've been working on this branch a few months but decided to PR it now as I feel it might help with #1421 (comment).

Comment on lines -33 to 37
SECP256K1_FE_VERIFY_FIELDS
#ifdef VERIFY
int magnitude;
int normalized;
#endif
} secp256k1_fe;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tried/considered including field.h instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't it create a circular dependency?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some sense, yes, but it's not a problem because the include guards should break any loops.

If you take that to the extreme, we could also have a single headers.h that includes all internal headers and include headers.h (almost) everywhere. That's a rather simple solution. I'm not convinced that this is very elegant, but it gets the job done...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not a problem because the include guards should break any loops.

Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful. FWIW, I've already tried the testing script that keeps an original header unmodified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful.

You mean problems will occur if we move code from a header to a source file?

FWIW, I've already tried the testing script that keeps an original header unmodified.

I don't understand. Can you rephrase?

Copy link
Member Author

@hebasto hebasto Sep 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful.

You mean problems will occur if we move code from a header to a source file?

Yes. I mean:

mv src/field_10x26.h src/field_10x26.c
gcc -c src/field_10x26.c -o src/field_10x26.o

That effectively renders src/field_10x26.h unavailable.

FWIW, I've already tried the testing script that keeps an original header unmodified.

I don't understand. Can you rephrase?

A modified script looks like that:

cp src/field_10x26.h src/field_10x26.c
gcc -c src/field_10x26.c -o src/field_10x26.o

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build ci meta/development processes, conventions, developer documentation, etc. refactor/smell
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants